1. Field of Invention
The invention relates to a process for computer-aided, block-based modeling, to prepare a first block diagram in a first model plane—of a first abstraction stage—there being at least one block, and for horizontal exchange of data between several blocks, the blocks being able to be connected to one another by horizontal data transfer means. Moreover, the invention also relates to a modeling means for preparing a first block diagram in a first model plane—of a first abstraction stage—and there can be at least one block in the first model plane, and for horizontal exchange of data, several blocks being connectable to one another by horizontal data transfer means.
2. Description of Related Art
Computer-aided processes and modeling means for block-based modeling, for the purposes of this invention, in the area of technical research and development, have the objective of mathematically mapping and representing any type of process and simulating it by using numerical methods. The probably most common means for executing this modeling is a block diagram representation known mainly from system theory, in which the blocks used acquire a certain mathematical functionality—from simple algebraic operations to complex dynamic timing—and processes of almost any complexity can be modeled by a block diagram by interconnection of different blocks in terms of signals.
This process is conventionally carried out on computer-aided modeling means, the mathematical modeling of a technical-physical process itself often being only the first step of a plurality of development steps, as can be found, for example, in the area of the development and use of electronic control systems or electronic control units.
It is helpful to an understanding of the invention to briefly outline the typical working process in handling of computer-aided modeling processes and the modeling means directed at them. In this respect, reference is made, by way of example, to the aforementioned use of electronic control units, which use is especially well suited because it shows the diverse requirements for the modeling processes under consideration here (keyword “V-cycle”); of course, the modeling processes are not limited to this application which is used only as an example.
In practice, preparation of a mathematical model of any technical process is not an end in itself which is used purely to acquire knowledge, rather the acquired process should generally be subjected to planned control, control being defined here not only as what is defined in a system theoretical sense narrowly as control, but any type of planned influence, for example, also by feedback control.
Within the framework of so-called function development, therefore, the block diagram which describes the process to be influenced is used and a control modeled in the form of a block diagram is added to it so that the effect of control on the process within the framework of numerical simulation—without a physical connection to the real process—can be safely observed and the control can be adapted. This model or block diagram is, first of all, abstract, i.e., without any reference to a possible hardware implementation and without reference to possible linkage of the control to a real process; it is called a function model below.
To test the control concept which has been tried with the function model in a real process, by so-called rapid control prototyping, the block diagram, or parts of it, is translated by the modeling environment automatically into a control program which can run on the target hardware—conventionally an electronic control unit. This electronic control unit is integrated via its outside world interfaces into the real physical process, and accepts the states of the process to be influenced which are of interest via its outside world interfaces and outputs the corresponding influence quantities—manipulated variables—over these interfaces to the process.
At this point, it is immediately obvious that, when the control program is produced, the special target hardware together with its outside world interfaces must always be considered in order to obtain a control program which can run on this target hardware. For this reason, the target hardware and its outside world interfaces are already considered in the modeling by the properties of the electronic control unit being represented by hardware blocks and integrated into the existing abstract function model. The overall block diagram which has been prepared in this way accordingly comprises not only the function model, but also a hardware model or hardware block diagram which is associated with the function model.
Since the hardware blocks which describe the hardware represent entirely different hardware properties, they may describe entire I/O devices or components of them (for example, channels of digital/analog converters, digital I/O channels) as well as complex, parameterizable modules (for example, data busses and definition of the messages transmitted by them and their timing behavior, generation/analysis of signal characteristics by digital signal processors), the properties of which can be set in the block diagram, for example, by dialog windows or similar means.
The described computer-aided modeling processes or modeling means are known from the prior art. The modeling means MATLAB and Simulink (TheMathWorks: “MATLAB, The Language of Technical Computing”, version 7.0.4, March 2005, or TheMathWorks: “Simulink, Simulation and Model-Based Design”, version 6.2, March 2005) allows execution of a block-based modeling process which allows the arrangement of blocks which form a block diagram in a first and sole model plane, this first and sole model plane being assigned to a first highest abstraction stage. This means that the complete model is present as an overall block diagram in a first and sole model plane and is not, for example, distributed among different model planes of the same first abstraction stage.
Such an overall block diagram known from the prior art can have other model planes, but these other model planes belong to another, lower abstraction stage, i.e., they constitute a part of the overall block diagram which is at the higher abstraction stage and which is located on the first model plane in a higher degree of detail and on a model plane of a lower abstraction stage than the first abstraction stage. Therefore, the model planes of a lower abstraction stage, in fact, do not deliver any new contribution to the overall block diagram, but instead represent a component which already exists in the block diagram of the first model plane of the first and highest abstraction stage, only in another, more detailed form.
In the prior art, this is accomplished, for example, by sub-block diagram blocks which are located, for example, in the first and sole model plane of the first abstraction stage; such a block could represent, for example, a PID controller. This sub-block diagram block represents nothing more than a block diagram in another model plane which is assigned in any case to a lower abstraction stage. Such a sub-block diagram block which is located in the first model plane of the first abstraction stage would have, for example, only one block input and one block output, but it would not yield any further information about its internal implementation.
The internal structure of the sub-block diagram block is only disclosed by another block diagram in another model plane of a lower abstraction stage which is represented by the sub-block diagram block in the first model plane of the first abstraction stage. In this further model plane of a lower abstraction stage, for example, it could be shown or mathematically modeled by another block diagram that the PID controller is implemented by amplification, integration and differentiation of an input signal, the cumulative value of these three signal transforms then being output.
Moreover, the possibility of using sub-block diagram blocks, in turn, in sub-block diagram model planes is known, and they in turn represent sub-block diagram model planes of a still lower abstraction stage or sub-block diagrams in these sub-block diagram model planes.
The described procedure in the known computer-aided and block-based modeling with respect to support of efficient working sequences, transparency, ability to structure and adapt models has various disadvantages. Because in the known processes and in the known modeling means for block-based modeling the overall block diagram is modeled completely in a first model plane of a first abstraction stage, meaningful functional organization and structuring of the block diagram are possible only to a limited degree; all components of the block diagram always appear with equal rights. For this reason, treatment based on division of labor and organization of the block diagram are not possible in an optimum manner.
Grouping of coherent model parts is possible by the organization element of the sub-block diagram blocks and the sub-block diagram model planes associated with them, but there is the danger of increasing confusion within the overall block diagram, since the usage of nested sub-block diagram blocks creates a labyrinthine interleaving of the overall block diagram. Mainly with consideration of the fact that many of the blocks used in practice can be configured and must also be configured for meaningful use of the block diagram in simulation and code generation, and with further consideration of the fact that this configuration is undertaken directly over the block (for example, by a dialog window being opened upon activation—“double click”—of the block for input of parameters or by the block's having diverse block inputs via which parameterization can be undertaken by external interconnection to other blocks), it is immediately apparent that reconfiguration of block properties for large models is a time-consuming and error-prone task. This applies more, the further it is considered that the models of more demanding processes or systems can easily comprise several hundred thousand blocks and more.
A similar problem arises in a case which can be encountered in practice in which the model or the block diagram must be adapted to partially or completely altered target hardware. In this case, in the process known from the prior art or using the known modeling means, the existing hardware-describing blocks must be exchanged and replaced by new blocks which described the new target hardware (for example, TheMathWorks: “xPC Target, For Use With Real-Time Workshop”, User's Guide, version II, March 2005).